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SYSTEMS ET PROCEDE DE GESTZON DE SECURITE 
D' APPLICATIONS INFORMATIQUES 

L' invention concerne les systdmes inf onnatiques et, 
plus particuli&rement dans de tels syst ernes, un systdme 
et procede pour gerer les conditions d'acces aux 
diffSrentes applications qui sont susceptibles d'etre 
5 mises en oeuvre par ces systemes inf ormatiques. 
L' invention est pr6f erentiellement, ma is non 
limitativement, destinee a dtre mise en oeuvre dans les 
microprocesseurs des cartes a puce quel que soit le 
domaine d' utilisation: sant€, banque, transport, 
10 telephone mobile etc . . . 

Les procedes connus de gestion de securite 
presentent les principaux inconvenients suivants: 

- le premier inconvenient est une obligation de 
presenter une hierarchie pour s§lectionner une 

15 application, c'est-a-dire qu'il faut passer par une 
chemin de selection impose en commengant par 
1' application "grand-mere", puis 1 'application "mere" 
pour arriver a 1' application "fille" , c'est-S-dire un 
chemin de selection analogue a celui pour sfelectionner 

20 un fichier dans un repertoire d'un disque dur ; en 
outre, il n'y a rien de pr6vu au sujet de la securite. 

II n'existe done pas de relation entre le niveau de 
la selection et celui de la securite. 

- Le second inconvenient est de limiter le sombre 
25 de niveaux de sfecuritS ou le nombre d' applications. En 

effet, a chaque application est dedi£ un registre de 
s6curit6 qui memorise les droits acquis par cette 
application par la connaissance de secrets. Pour 
raj outer n niveaux, c'est-a-dire disposer d'une serie 
30 multi-applicative, il faut associer, par exemple, un 
registre de security £ chaque application, ce qui 



conduit a utiliser une partie importante de la memoire 
rapide oil sont stockes les registres de security. Comae 
la capacity de cette memo ire rapide est limitfee, il 
n'est pas souhaitable d'y stocker de nombreux registries 
5 de s6curit6. C'est ainsi que dans certains systemes, le 
nombre de niveaux hi^rarchiques ou le nombre 
d' applications a et€ limite a trois, soit trois 
registres de s6curit6. 

- Le troisifeme inconvenient est d'empdcher 
10 "1' Emancipation" simple des applications, c'est-a-dire 

rendre une application "fille" indfependante de son 
application "mfere" . En effet, lors d'une creation d'une 
nouvelle application, il est indispensable d' utiliser 
les droits et secrets de 1 'application "mfere" qui sont 

15 les seuls disponibles et ce jusqu'a la creation des 
secrets propres a 1' application "fille". 

Le but de la presente invention est de mettre en 
oeuvre un proc6d6 de gestion de sfecuritfe d' applications 
informatiques qui ne prfesente pas les inconvenients 

20 exposes ci-dessus et qui permet done: 

- de ne pas etre limits en nombre de niveaux 
hierarchiques ou nombre d' applications, et 

- de rendre un application "fille" indEpendante de 
1 'application "m&re" sans passer par cette dernifere du 

25 point de vue de la securite. 

L' invention concerne done un systfeme de gestion de 
la s6curit6 d' applications informatiques, caracteris§ 
en ce que: 

- les applications informatiques sont enregistr^es 
30 dans des fichiers repertoires organises suivant une 

arborescence a n niveaux, le repertoire de niveau 1 
6tant de niveau le plus eleve, et 

- un nombre r de registres de securite pouvant 6tre 
affectes chacun a un seul repertoire et chaque registre 



de security contenant 1' ensemble des droits ou secrets 
SI a Sp qui ont 6t§ octroy6s sous un repertoire. 

L' invention concerne ega lenient un procede de 
gestion de la securite d' applications inf ormatiques 
5 dans le systfeme de gestion deer it ci-dessus, 
caracterisfe en ce qu'il comprend les Stapes suivantes 
consistant fi: 

(a) m&noriser dans des registres de sfecurite les 
droits octroy6s sous un repertoire selon des regies 

10 d€termin€es, 

(b) rechercher dans l'arborescence les secrets 
pr £sent£s , et 

(c) verifier la connaissance equivalente a un (ou 
des) droits au niveau de 1 ' application informatique 

15 pour satisfaire les conditions d'acces. 

D'autres caracteristiques et avantages de la 
presente invention apparaltront a la lecture de la 
description suivante d' exemples particuliers de 
realisation, ladite description etant faite en relation 

20 avec les dossiers joints dans lesquels: 

- la figure 1 est un exemple de structure 
arborescente des repertoires; 

- les figures 2.1 a 2.14 illustrent des exemples 
d' application des trois regies d' attribution ou de 

25 dfesaf feet ion d'un registre de s£curit6 a un rfepertoire; 

- les figures 3.1a a 3.6a et 3.1b a 3.6b illustrent 
des exemples d 'application de la regie de presentation 
d'un secret; et 

- les figures 4.1 a 4.6 illustrent des exemples 
30 d' application de la regie de verification de 1' octroi 

du droit requis. 

L' invention sera decrite dans son application a une 
carte a puce et, plus precis€ment, a un microprocesseur 
utilise dans une carte a puce. Cependant, elle est 



egalement applicable a tout systeme informatique ou il 
est necessaire ou simplement souhaitable que certains 
services ou fonctions offerts par le systeme soient 
accessibles seulement a certains utilisateurs ou 
oper ateurs . 

Dans le cas de cartes a puce, par exemple une carte 
bancaire ou une carte de telephone mobile, les services 
ou fonctions qui sont a la disposition de l'utilisateur 
peuvent etre soumis a autorisation selon le type 
d'abonnement souscrit, ces autorisations (ou droits) 
etant octroyees en prouvant la connaissance de secrets 
qui permettent l'acces aux fichiers necessaires a la 
mise en oeuvre du service ou de la fonction. 

Dans la suite de la description, les definitions 
suivantes seront adoptees: 

- Un fichier est un ensemble de donnees pouvant 
4tre protegees par des conditions d'acces. 

- Un repertoire Rep est un ensemble de fichiers 
et/ou de repertoires selon une organisation 
arborescente (figure 1); habituellement un repertoire 
est dedie uniquement a une application. 

- Les conditions d'acces a un fichier ou a un 
repertoire Rep definissent les criteres a remplir, 
telle que la presentation d'un code secret ou une 
authentification externe, pour pouvoir effectuer telle 
ou telle fonction sur le fichier ou le repertoire; 

- Les fichiers et repertoires sont organises 
suivant une arborescence a plusieurs niveaux dont le 
repertoire de plus haut niveau (niveau 1) est appele 
"repertoire racine" ou racine de 1' arborescence. Un 
niveau caracterise les repertoires ayant le meme degre 
hierarchique. L' utilisation de repertoires permet de 
structurer les donnees d'une carte a puce, sur la 
figure 1, seuls les repertoires Repl, Rep2, Rep31, 




Rep32, Rep41, Rep42, Rep51 et Rep52 ont ete presentes 
et chacun peut contenir un ou plusieurs fichiers. Le 
repertoire Repl est la racine de 1 ' arborescence 
comprenant n=5 niveaux de repertoires, les repertoires 
5 Rep41 et Rep 4 2 appartenant au niveau i=4. 

- Un registre de security R contient 1' ensemble des 
droits qui ont 6te octroySs sous un repertoire et un 
droit est la preuve de la connaissance d'un secret qui 
est identifie par une reference telle qu'un nom, un 

10 numero, un identif icateur . II y a plusieurs facpons de 
prouver la connaissance d'un secret, par exemple par 
echange de la valeur du secret entre le terminal et la 
carte a puce ou par echange de donnees calculees a 
l'aide de ce secret: 1' operation s'appelle presentation 

15 du secret. 

D'une maniere generale, le fondement de la securite 
sur une carte a puce est de pouvoir subordonner 
1 'utilisation du service ou de la fonction de la carte 
a puce a la preuve de la connaissance d'un ou plusieurs 

20 secrets. Ainsi pour pouvoir utiliser une fonction de la 
carte, il faut: 

- que la carte a puce memorise prealablement cette 
preuve de la connaissance du ou des secrets dans un 
registre de securite, 

25 - que le porteur de la carte a puce ou le terminal 

prouve qu'il a connaissance du (ou des) secret (s) 
protegeant la f onct ion , 

- que la carte verifie, lors de 1 'utilisation de la 
fonction, que le (ou les) secret (s) est (sont) bien 

30 connu(s) . 

L' invention reside dans les etapes du procede 
consistant a: 

(a) memoriser dans la carte a puce la connaissance 
du (ou de(s) ) secret(s) c'est-a-dire les droits 



octroyes, selon des regies d' attribution et de 
disaffection d'un registre de sicurite a un repertoire, 

(b) rechercher dans 1' arbor escence le (ou les) 
secret ( s ) presente ( s ) , 
5 (c) verifier la connaissance du (ou des) secret (s) 

pour remplir les conditions d'acces. 

Pour memoriser la connaissance d'un secret dans une 
carte & puce (6tape (a)), il est necessaire de 
presenter correctement le secret, ce qui revient 3 

10 prouver que 1'ext^rieur, par exemple un terminal ou un 
porteur de carte, a la connaissance dudit secret, cette 
connaissance lui conf6rant un droit d' utilisation de 
fonctions ou de services offerts par la carte. C'est le 
droit qui est memorise dans un registre de sScurite a 

15 raison d'un registre par application. 

Un registre de s6curit6 R comprend un nombre p de 
chiffres ou positions, chaque position etant affectee a 
la connaissance d'un secret correspondant & un droit 
octroy^. Un registre d p=8 positions pourra enregistrer 

20 la connaissance de huit secrets SI a S8 qui 
correspondront & huit droits octroySs. 

Le nombre r de registres de sfecurite R peut etre 
quelconque et 1' exemple qui sera dScrit en comportera 
r=3. Les registres de security ne sont pas d&di&s a un 

25 niveau ou & un repertoire donne comme dans 1'art 
anterieur et le lien entre un repertoire et un registre 
de s6curit6 est dynamique, c'est-&-dire que ce lien 
peut 6tre cr66 ou rompu conformfement aux regies du 
proc6d6 selon 1' invention. 

30 Pour memoriser un droit dans un repertoire, il faut 

d'abord attribuer ou dfesaffecter un registre de 
security a un repertoire selon les trois regies RGl a 
RG3 suivantes: 
R&qle RGl ; 




Un rcgistre est attribue au repertoire courant dSs 
lors qu'un droit est octroye sous ce repertoire , par 
exemple un code secret ou une authentif ication. Si un 
droit a deja ete octroye sous ce repertoire, le 
5 registre dedie & celui-ci est mis a jour. 

Rdole RG2 ; 

La selection d'un nouveau repertoire entralne la 
perte du lien reliant l'ancien repertoire courant a son 
registre de securite sauf si le repertoire selections 
10 est "fils" de l'ancien repertoire courant. 

Regie RG3 ; 

Si le nombre r de registres de securite est sature, 
c'est-S-dire que les r=3 de 1' exemple d6crit sont 
utilises, le registre le plus anciennement affecte, 

15 c'est-^-dire le niveau le plus haut dans 
1'arborescence, est attribue au nouveau repertoire 
courant conformiment a la rfegle RG1 . 

II est a remarquer que 1' application de la regie 
RG2 rend impossible 1' attribution de deux registres de 

20 securite a un m§me niveau, de sorte que 1' attribution 
d'un registre de securite & un repertoire peut etre 
materialisee par un niveau hierarchique Ni affecte au 
registre de securite concern^, i variant de 1 a n. 

Les figures 2.1 a 2.14 illustrent des applications 

25 des regies RG1, RG2 et RG3. Sur ces figures et les 
autres, un cercle noir designe un repertoire, un cercle 
gris designe un repertoire selectionne et un cercle 
blanc designe un repertoire selectionne avec un droit 
leve. 

30 La figure 2.1 illustre l'absence de selection d'un 

repertoire tandis que les figures 2.2 et 2.3 illustrent 
respect iventent la selection des repertoires Repl et 
Rep2 . 



Ainsi, 1' application de la regie RG1 est illustree 
dans les figures 2.4, 2.6, 2.8, 2.10, 2.12 et 2.14. La 
figure 2.4 illustre la presentation d'un secret sous le 
repertoire Rep2 de niveau N2. La figure 2.6 illustre la 
5 presentation d'un secret sous le repertoire Rep31 de 
niveau N3. La figure 2.8 illustre la presentation d'un 
droit sous le repertoire Rep41 de niveau N4. La figure 
2.10 illustre la presentation d'un droit sous le 
repertoire Rep5l de niveau N5. La figure 2.12 illustre 

10 la presentation d'un droit sous le repertoire Rep41. La 
figure 2.14 illustre la presentation d'un droit sous le 
repertoire Rep42. 

L' application de la regie RG2 est illustree par les 
figures 2.5, 2.7 et 2.9 en ce qui concerne le maintien 

15 du lien entre un registre de securite et son repertoire 
lors de la selection d'un nouveau repertoire "fils" de 
celui-ci. 

Les figures 2.5, 2.7 et 2.9 illustrent 
respectivement la selection du repertoire Rep31, Rep41 
20 ou RepSl. 

L' application de la regie RG2 est illustree par les 
figures 2.11 et 2.13 en ce qui concerne la rupture du 
lien entre un registre de securite et son repertoire. 
Ainsi, la figure 2.11 illustre la selection du 
25 repertoire Rep41 tandis que la figure 2.13 illustre la 
selection du repertoire Rep42. 

L' application de la regie RG3 est illustree par la 
figure 2.10 dans laquelle le registre le plus 
anciennement affecte Rl est attribue au nouveau 
30 repertoire seiectionne Rep51. 

L'etape (a) consistant a memoriser les droits 
attaches & la connaissance des secrets etant realisee, 
l'etape (b) consistant a rechercher dans 1' arbor escence 



le secret presente par le porteur de la carte 4 puce ou 
par le terminal peut etre mise en oeuvre. 

Un secret presente au niveau d'une application 
confere un droit d'utilisation au niveau de cette meme 
5 application. Ainsi, la presentation reussie d'un secret 
au sein d'une application de niveau hi#rarchique Ni met 
a jour le registre de securite dedie a ce niveau 
hierarchigue, conf ormement a la regie RG1 , meme si le 
secret presente est physiquement situe dans un niveau 
10 hiSrarchique sup6rieur. 

La regie de presentation d'un secret est la 
suivante : 

Rfeqle RG4 : 

La presentation d'un secret de reference s revient 
15 a verifier que le porteur de la carte §l puce ou le 
terminal connait la valeur du premier secret de 
r€f6rence S trouve en parcourant 1'axe hierarchique de 
1' application courante vers le repertoire racine. 

La presentation du secret de reference s au niveau 
20 de 1' application courante situee au niveau hiferarchique 
Ni est realisee par les etapes intermediaires suivantes 
consistant a: 

(bl) rechercher un secret de reference S dans le 
repertoire courant, c'est-S-dire au niveau Ni, a l'aide 
25 du systeme de gestion de s§curite et verifier 
1' existence de ce secret au sein de 1' application; 

(b2) si ce secret existe, verifier que la 
presentation du secret est reussie, par exemple valeur 
pour un code secret, cryptogramme pour une cie, etc 



30 



Si la presentation est reussie, le droit associe au 
secret de reference S est octroye au niveau de 
1' application courante de niveau Ni. 



10 

Si la presentation a echoue, le droit associe au 
secret de reference S n'est pas octroye et la tentative 
de presentation est terminee. 

(b3) Si le secret de reference S n' existe pas au 
5 sein de 1' application courante de niveau Ni, rechercher 
si un secret de meme reference existe au sein de 
1' application parente de niveau N(i-l) de 1' application 
courante • 

(b4) Si le secret existe au niveau de 1' application 
10 parente de niveau N(i-l) , verifier que la presentation 
est reussie. 

Si la presentation est reussie, le droit associe au 

secret de reference S est octroye au niveau de 

1' application courante de niveau Ni. 
15 Si la presentation a echoue, le droit associe au 

secret de reference S n'est pas octroye et la tentative 

de presentation est terminee. 

(b5) Si le secret de reference S n' existe pas au 

sein de 1' application parente de niveau N(i-l), 
20 rechercher le secret de reference S au niveau N(i-2) 

suivant l'axe hi6rarchique, et ainsi de suite tant que 

1 'existence d'un secret de reference S n'a pas ete 

decouverte . 

(b6) Si le secret de reference S n'a pas ete 
25 trouve, la tentative de presentation est terminee. 

Plusieurs exemples d' application de la regie RG4 
sont il lustres sur les figures 3.1a a 3.6a et 3.1b & 
3.6b. Les figures 3.1a et 3.1b, 3.2a et 3.2b, 3.3a et 
3.3b correspondent & des exemples oil le droit est 
30 octroye tandis que les figures 3.4a et 3.4b, 3.5a et 
3.5b, 3.6a et 3.6b correspondent a des exemples oil le 
droit n'est pas octroye. 

Sur la figure 3.1a, le secret S3 existe en local 
sous le repertoire Rep41 et aucun registre n'est 
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attribue au repertoire Rep41. Sur la figure 3 .lb, la 
connaissance du secret S3 est prouvee ; un registre R3 
est affectfe au repertoire Rep41 de niveau N4 et le 
droit est octroye. 
5 Sur la figure 3.2a, le secret S3 existe en local 

sous le repertoire Rep41 et un registre R3 est deja 
attribue au repertoire Rep41. La connaissance du secret 
S3 est done prouvee et le registre de security R3 
affecte au repertoire Rep41 est mis & jour (S3) de 

10 sorte que le droit est octroye (figure 3.2b). 

Sur la figure 3.3a, le secret S2 n' existe pas en 
local sous le repertoire Rep41 ; un registre R3 est 
deja attribue au repertoire Rep41 et un secret S2 
existe d la fois sous les repertoires Rep2 , Repl, Rep 4 2 

15 et RepSl. La connaissance du secret S2 est done prouvee 
et le registre de securite affecte au repertoire Rep41 
est mis a jour de sorte que le droit est octroye 
(figure 3.3b) . 

Sur la figure 3.4a, le secret S2 n' existe pas en 

20 local sous le repertoire Rep41 ; un registre R3 est 
d6j& attribue au repertoire Rep41 et un secret S2 
existe a la fois sous les repertoires Rep2, Repl, Rep42 
et Rep51. La connaissance du secret S2 n'est done pas 
prouvee de sorte que le registre de securite R3 affecte 

25 au repertoire Rep41 n'est pas mis a jour et que le 
droit n'est pas octroye (figure 3.4b) . 

Sur la figure 3.5a, le secret S2 n' existe pas en 
local sous le repertoire Rep41 ; un registre R3 est 
dejS attribue au repertoire Rep41 et un secret S2 

30 existe 4 la fois sous les repertoires Rep2, Repl, Rep42 
et RepSl. La connaissance du secret S2 n'est done pas 
prouvee de sorte que le registre de securite R3 affecte 
au repertoire Rep41 n'est pas mis a jour et le droit 
n'est pas octroye (figure 3.5b), 
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Sur la figure 3.6a, le secret S2 n' existe pas en 
local sous le repertoire Rep41 ; un registre R3 est 
deja attribue au repertoire Rep41 et un secret S2 
existe a la fois sous les repertoires Rep2, Repl, Rep42 
5 et Rep51. La connaissance du secret S2 n'est pas 
prouvfee de sorte que le registre de s6curite R3 affecte 
au repertoire Rep41 n'est pas mis a jour et le droit 
n'est pas octroy^ (figure 3.6b). 

L'etape (c) consiste a verifier que la connaissance 
10 du (ou des) secret (s) pour remplir les conditions 
d'acc^s, c'est-a-dire verifier que le secret protegeant 
1' utilisation d'une fonction et d'un service de la 
carte a puce est bien connu du monde exterieur, c'est- 
a-dire que le droit requis a bien ete octroye. 
15 A cet effet, 1' invention met en oeuvre une 

cinquieme regie RG5 qui s'enonce de la maniere 
suivante: 

Regie RG5 : 

Une fonction, necessitant la connaissance d'un 
20 secret S, est autoris£e si et seulement si, en 
parcourant l'arborescence suivant 1'axe hierarchique de 
1' application courante vers 1' application racine, le 
premier secret S rencontre est connu, c'est-a-dire 
correctement presente, par au moins l'une des 
25 applications appartenant a la section arborescente 
ayant pour bornes 1' application courante et 
1' application contenant le secret S, ces applications 
pouvant etre confondues si le secret S existe dans 
1' application courante. 
30 Pour realiser l'etape (c) , le systeme de gestion 

doit effectuer les etapes suivantes consistant a: 

(cl) verifier qu'un registre de securite est 
associe a 1' application courante du niveau Ni; 
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(c2) autoriser la fonction si le registre de 
security contient le droit requis et terminer la 
verification ; 

(c3) rechercher 1' existence du secret de reference 
5 S au sein de 1 'application courante de niveau Ni si 
aucun registre de securite n'est associe & 
1 # application courante ou si le registre associe ne 
contient pas le doit requis; 

(c4) refuser la fonction et terminer la 
10 verification si le secret existe au sein de 
1' application courante; 

(c5) verifier qu'un registre de securite est 
associe a 1' application parente de niveau N(i-l) de 
1' application courante si le secret de reference S 
15 n' existe pas au sein de 1' application courante de 
niveau Ni; 

(c6) autoriser la fonction et terminer la 
verification si le registre de securite associe a 
1' application parente contient le droit requis pour 
20 utiliser la fonction; 

(c7) rechercher 1' existence du secret de reference 
S au sein de 1' application parente de niveau N(i-l) de 
1' application courante si aucun registre de securite 
n'est associe & 1' application parente ou si le registre 
25 de security associe ne contient pas le droit requis; 

(c8) refuser la fonction et terminer la 
verification si le secret de reference S existe au sein 
de l'application parente de niveau N(i-l); 

(c9) verifier qu'un registre de securite est 
30 associe a l'application grand-parente de niveau N(i-2) 
de l'application courante suivant l'axe hierarchique de 
l'application courante vers l'application racine, si le 
secret de reference S n' existe pas au sein de 
l'application parente de niveau N(i-l), 
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et ainsi de suite tant que 1' existence du secret de 
reference S n'a pas ete decouvert; 

(clO) refuser la fonction et terminer la 
verification si le secret n'a pas ete decouvert. 

Les figures 4.1 et 4.2 illustrent deux exemples de 
fonction autorisee tandis que les figures 4.3, 4.4, 4.5 
et 4.6 illustrent quatre exemples de fonction refusee. 

Sur la figure 4.1, la fonction est acceptee car le 
secret S3 existe en local, et que celui-ci est connu 
sous le repertoire Rep41. 

Sur la figure 4.2, la fonction est acceptee car le 
secret SI n'existe pas en local mais que celui-ci est 
connu sous le repertoire Rep2. 

sur la figure 4.3, la fonction est rejetee car le 
secret S3 existe en local sous le repertoire Rep41 et 
qu'aucun droit n'a ete octroye sous ce repertoire. 

sur la figure 4.4, la fonction est rejetee car le 
secret S3 existe en local sous le repertoire Rep 41 et 
que, bien qu'un registre de securite R3 soit affecte au 
repertoire Rep41, la connaissance du secret S3 n'a pas 
ete prouvee. 

Sur la figure 4.5, la fonction est rejetee car le 
secret S2 , qui n'existe pas en local sous le repertoire 
Rep41, ni dans le repertoire Rep31, existe sous le 
repertoire Rep2 et qu'aucun registre de securite n'est 
affecte au repertoire Rep2 . II est a remarquer que la 
fonction est rejetee bien qu'un secret S2 soit connu 
sous le repertoire Repl. 

Sur la figure 4.6, la fonction est rejetee car le 
secret SI n'a pas ete trouve en parcourant l'axe 
hierarchique du repertoire Rep41 vers le repertoire 
Repl et ce, bien qu'un secret SI existe sous les 
repertoires Rep51 et Rep32. 
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RE VEND I CAT I ONS 



1. Systdme de gestion de la securite d' applications 
inf ormatiques, caracterisS en ce que: 

- les applications inf ormatiques sont enregistrfees 
dans des fichiers de repertoires (Repl, Rep2, Rep31, 

5 Rep32, Rep41, Rep 42, Rep51, Rep52) organises suivant 
une arborescence a n niveaux, le repertoire de niveau 1 
(Repl) etant de niveau le plus el eve, et 

- un nombre r de registres de securite (R) pouvant 
etre affectes chacun a un seul repertoire et chaque 

10 registre de s6curite (R) contenant 1' ensemble des 
droits ou secrets SI a Sp qui ont ete octroy es sous un 
repertoire. 

(TTl Proc6d6 de gestion de la securite d' applications 
inf ormatiques dans un systeme selon la revendication 1, 
15 caracterisS en ce qu'il comprend les Stapes suivantes 
consistant hi 

(a) mfemoriser dans des registres de security 
(R) les droits octroySs (SI a Sp) sous un 
repertoire (Rep) selon des regies 

20 determinees (RG1, RG2 , RG3 ) , 

(b) rechercher dans 1' arborescence le secret 
presents , et 

(c) verifier la connaissance du (ou des) droits 
au niveau de 1 'application inf ormatique. 

25 3, ProcSde selon la revendication 2, caracterisS en 

ce que les regies de memorisation de l'etape (a) sont 
les suivantes: 

(RG1) : attribution d'un registre de securite (R) 
au repertoire courant des 1' octroi d'un 
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droit sous ce repertoire ou mise a jour 
dudit registre de securite si un droit a 
deja ete octroy e sous ce repertoire , 

(RG2) perte du lien reliant 1'ancien repertoire 
5 courant a son registre de securite lors de 

la selection d'un nouveau repertoire sauf 
si le repertoire seiectionne est le fils de 
1'ancien repertoire courant; 

(RG3) attribution du registre de security le plus 
10 anciennement attribue au nouveau repertoire 

courant si les registres de s£curite sont 
tous attribues, 

4. Proc6de selon la revendication 2 ou 3, 
caracterise en ce que l'etape (b) consiste & appliquer 

15 la regie suivante consistant a: 

(RG4) verifier que le secret presente (S) est 
connu dans le repertoire courant (Ni) ou 
dans un repertoire de niveau super ieur. 

5. Procede selon la revendication 2, 3 ou 4, 
20 caracterise en ce que 1'etape (b) comprend les etapes 

intermediaires suivantes consistant kz 

(bl) rechercher un secret dans le repertoire 
courant de niveau (Ni) et verifier 
1' existence du secret (S) au sein de 
25 1' application, 

(b2) si ce secret (S) existe, verifier que la 
presentation du secret est reussie; 
= si la presentation est reussie, le droit 
associe au secret (S) est octroy6 au niveau 
30 (Ni) de l'application courante; 
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= si la presentation a echoue, le droit 
associe au secret (S) n'est pas octroye et 
la tentative de presentation est terminee; 
(i>3) si ce secret (S) n' existe pas dans 
5 1' application courante de niveau (Ni) , 

rechercher si ce secret (S) existe au sein 
de 1' application parente de niveau N(i-l) . 
(b4) Si ce secret (S) existe dans 1' application 
parente de niveau B(i-l) , verifier que la 

10 presentation est r€ussie: 

= si la presentation est reussie, le droit 
associe au secret (S) est octroye dans 
1'application courante de niveau (Ni) , 
= si la presentation a 6choue, le droit 

15 associe au secret (S) n'est pas octroye et 

la tentative de presentation est terminee; 
(b5) si le secret n' existe pas au sein de 
1'application parente de niveau N(i-l) , 
rechercher 1 'existence du secret (S) au 

20 niveau de 1'application de niveau N(i-2) 

suivant l'axe hi6rarchique et verifier que 
la presentation est reussie, 

et ainsi de suite jusqu'au niveau 
hierarchique le plus eleve tant que 
25 1' existence du secret (S) n'a pas ete 

decouvert ; 

(b6) Si le secret (S) n'a pas ete decouvert, la - 

tentative de presentation est terminee. 
6. Procede selon l'une des revendications 
30 precedentes 2 a 5 # caractSrise en ce que l'etape (c) 
consiste Bl appliquer la regie suivante consistant a: 
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(RG5 ) Autor isation d ' une f onct ion nfecess itant la 
connaissance d'un secret (S) si et 
settlement si, en parcourant l'arborescence 
suivant l'axe hierarchique de 1' application 
5 courante vers 1' application racine, le 

premier secret (S) est connu par au mo ins 
l'une des applications appartenant h la 
section arborescente ayant pour bornes 
1' application courante et 1' application 
10 contenant le secret (S) . 

7. Proc6d6 selon l'une des revendications 
prec^dentes 1 a 6, caract6ris€ en ce que l'6tape (c) 
comprend les etapes suivantes consistant Sl: 

(cl) verifier qu'un registre de securite est 
15 assocife al 1' application courante du niveau 

Ni; 

(c2) autoriser la fonction si le registre de 
sgcuritfe contient le droit requis et 
terminer la verification; 

20 (c3) rechercher 1' existence du secret de 

reference S au sein de 1' application 
courante de niveau Ni si aucun registre de 
security n'est associe a 1' application 
courante ou si le registre associe ne 

25 contient pas le doit requis; 

(c4) refuser la fonction et terminer la 
verification si le secret existe au sein de 
1' application courante; 
(c5) verifier qu'un registre de s6curit£ est 

30 associS a 1 'application parente de niveau 

N(i-l) de 1' application courante si le 
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secret de reference S n' existe pas au sein 
de 1' application courante de niveau Ni; 
autoriser la fonction et terminer la 
verification si le registre de securite 
associe a 1' application parente contient le 
droit requis pour utiliser la fonction; 
rechercher 1' existence du secret de 
reference S au sein de 1' application 
parente de niveau N(i-l) de 1' application 
courante si aucun registre de securite 
n'est associ& a 1' application parente ou si 
le registre de securite associe ne contient 
pas le droit requis; 

refuser la fonction et terminer la 
verification si le secret de reference S 
existe au sein de 1' application parente de 
niveau N(i-l) ; 

verifier qu'un registre de securite est 
associe a 1' application grand-parente de 
niveau N(i-2) de 1 'application courante 
suivant l'axe hiferarchique de 1' application 
courante vers 1' application racine, si le 
secret de reference S n' existe pas au sein 
de l'application parente de niveau N(i-l), 
et ainsi de suite tant que 1' existence du 
secret de reference S n'a pas §te 
d^couvert ; 

refuser la fonction et terminer la 
verification si le secret n'a pas ete 
decouvert . 
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REVEND I CATIONS 



1. SystSme de gestion de la s6curit6 d' applications 
inf ormatiques, caracteris6 en ce que: 

- les applications inf ormatiques sont enregistrees 
dans des fichiers de repertoires (Repl, Rep2 , Rep31, 

5 Rep32, Rep41, Rep 42, Rep51, Rep52) organises suivant 
une arborescence a n niveaux, le repertoire de niveau 1 
(Repl) etant de niveau le plus 61 eve, et 

- un nombre r de registres de securite (R) pouvant 
dtre affectes chacun a un seul repertoire et chaque 

10 registre de security (R) contenant 1' ensemble des 
droits ou secrets SI a Sp qui ont ete octroySs sous un 
repertoire. 

£2^ Procede de gestion de la security d' applications 
inf ormatiques dans un systeme selon la revendication 1, 
15 caracteris6 en ce qu' il comprend les etapes suivantes 
consistant Slz 

(a) memoriser dans des registres de securite 
(R) les droits octroy es (Si a Sp) sous un 
repertoire (Rep) selon des rfegles 

2 0 d6termin€es (RG1 , RG2, RG3) , 

(b) rechercher dans 1 9 arbor escence le secret 
presente, et 

(c) verifier la connaissance du (ou des) droits 
au niveau de 1' application inf ormatique. 

25 3, Proc6d6 selon la revendication 2, caracterise en 

ce que les regies de memorisation de l'etape (a) sont 
les suivantes : 

(RG1) : attribution d'un registre de securite (R) 
au repertoire courant dfes 1' octroi d'un 
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droit sous ce repertoire ou mise a jour 
dudit registre de securite si un droit a 
d6jd 6t6 octroy^ sous ce repertoire, 
(RG2) perte du lien reliant l'ancien repertoire 
5 courant & son registre de securite lors de 

la selection d'un nouveau repertoire sauf 
si le repertoire seiectionne est le fils de 
l'ancien repertoire courant; 
(RG3) attribution du registre de securite le plus 
10 anciennement attribue au nouveau repertoire 

courant si les registres de securite sont 
tous attribues. 
4 • Proc6de selon la revendication 2 ou 3 , 
caracterise en ce que l'etape (b) consiste & appliquer 
15 la regie suivante consistant S: 

(RG4) verifier que le secret presente (S) est 
connu dans le repertoire courant (Ni) ou 
dans un repertoire de niveau super ieur. 
5. Procede selon la revendication 2, 3 ou 4, 
20 caracterise en ce que l'etape (b) comprend les etapes 
intermedia ires suivantes consistant a: 

(bl) rechercher un secret dans le repertoire 
courant de niveau (Ni) et verifier 
1' existence du secret (S) au sein de 
25 1' application, 

(b2) si ce secret (S) existe, verifier que la 
presentation du secret est r6ussie; 
= si la presentation est rSussie, le droit 
associe au secret (S) est octroye au niveau 
30 (Ni) de 1 'application courante; 
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= si la presentation a echoue, le droit 
associe au secret (S) n'est pas octroye et 
la tentative de presentation est terminee; 

(b3) si ce secret (S) n' existe pas dans 
1' application courante de niveau (Ni) , 
rechercher si ce secret (S) existe au sein 
de l'application parente de niveau N(i-l) . 

(b4) Si ce secret (S) existe dans l'application 
parente de niveau B(i-l) , verifier que la 
presentation est reussie: 

= si la presentation est reussie, le droit 
associe au secret (S) est octroye dans 
l'application courante de niveau (Ni) , 
= si la presentation a echoue, le droit 
associe au secret (S) n'est pas octroye et 
la tentative de presentation est terminee; 
(b5) si le secret n' existe pas au sein de 
l'application parente de niveau N(i-l) , 
rechercher 1 'existence du secret (S) au 
niveau de l'application de niveau N(i-2) 
suivant l'axe hierarchique et verifier que 
la presentation est reussie, 

et ainsi de suite jusqu'au niveau 
hierarchique le plus eleve tant que 
1' existence du secret (S) n'a pas ete 
decouvert; 

(b6) Si le secret (S) n'a pas ete decouvert, la 
tentative de presentation est terminee. 

6. Procede selon l'une des revendications 
precedentes 2 a 5, caracterise en ce que l'etape (c) 
consiste a appliquer la regie suivante consistant a: 
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(RG5) Authorisation d'une fonction n6cessitant la 
connaissance d / un secret (S) si et 
seulement si, en parcourant 1' arborescence 
suivant l'axe hiferarchique de 1' application 
5 courante vers 1* application racine, le 

premier secret (S) est connu par au mo ins 
l'une des applications appartenant a la 
section arborescente ayant pour bornes 
1' application courante et 1' application 
10 contenant le secret (S) . 

7. Proced§ selon l'une des revendications 
pr6c§dentes 2 Sl 6, caract6ris6 en ce que l'fetape (c) 
comprend les Stapes suivantes consistant £t: 

(cl) verifier qu'un registre de security est 
15 associ€ a 1 ' application courante du niveau 

Ni; 

(c2) autoriser la fonction si le registre de 
s£curit€ contient le droit requis et 
terminer la verification; 

20 (c3) rechercher 1' existence du secret de 

r£f€rence S au sein de 1 ' application 
courante de niveau Ni si aucun registre de 
s€curit£ n'est associ£ d 1' application 
courante ou si le registre associ€ ne 

25 contient pas le doit requis; 

(c4) refuser la fonction et terminer la 
verification si le secret existe au sein de 
1' application courante; 
(c5) verifier qu'un registre de s€curit6 est 

30 associ6 & 1' application parente de niveau 

N(i-l) de 1 'application courante si le 
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secret de rfefference S n' existe pas au sein 
de 1' application courante de niveau Mi; 
autoriser la fonction et terminer la 
vferification si le registre de sfecuritfe 
assocife & 1' application parente contient le 
droit requis pour utiliser la fonction; 
rechercher 1' existence du secret de 
rfefference S au sein de 1' application 
parente de niveau N(i-l) de 1' application 
courante si aucun registre de sfecurite 
n'est assocife & 1' application parente ou si 
le registre de sfecurite assocife ne contient 
pas le droit requis; 

refuser la fonction et terminer la 
vferification si le secret de rfefference S 
existe au sein de 1' application parente de 
niveau N(i-l) ; 

verifier qu'un registre de sfecuritfe est 
assocife & 1' application grand-parente de 
niveau N(i-2) de 1 'application courante 
suivant l'axe hiferarchique de l'application 
courante vers 1' application racine, si le 
secret de reference S n' existe pas au sein 
de 1' application parente de niveau N(i-l), 
et ainsi de suite tant que 1' existence du 
secret de rfefference S n'a pas fetfe 
dfecouvert ; 

refuser la fonction et terminer la 
vferification si le secret n'a pas fetfe 
dfecouvert . 
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